\section{Specification of Network Simulator Design (Scenario II)(\emph{Erlang Slowly})}
The important different between single-queue and network is that each packet should go through the network by a special path. In order to calculate the delay time and the lost rate, I add the path and each path's timestamps to the packet record. So I'll describe the data structure of the program and then introduce the implementation of the network simulator.

\subsection{Data Structure}
In \erlang, there is no class concept. The most thing we used for recording data is the \emph{tuple}, or we call it \emph{record} when saving the structure to a \erlang{} file(with suffix:\emph{hrl}, please see Listing~\ref{src:edm_record}).
\lstinputlisting[label=src:edm_record,caption=The data structure of Event Driven Model]{../../include/event_model.hrl}

Even if we choose Event Driven Model for simulating, we also have some basic concepts(\emph{Router, Buffers, Buffer, Event, Packet and Timestamp}) for saving the simulate environment/status:
\begin{description}
  \item[Event\label{sec:erlang_event_model}] It is not \emph{arrive} type but \emph{departure} type, and it contains a packet.
  \item[Packet] It contains its length, the transmitting path, the router id where it's now and the timestamps that it has transmitted.
  \item[Timestamp] It contains its arriving time, waiting time and completing time.
  \item[Router] It should be assigned a id, and contain many buffers.
  \item[Buffer] It should save the status of simulating environment, such as the left buffer size, the transmitting rate, and the last completing time.
\end{description}

And all of these records are only data which are not owning any operate method. \textcolor{red}{The last of arriving time or the last of completing time and so on are meaning the last item's value of packet's timestamps field}.

\subsection{The basic environment for simulating}
Firstly, the main process should create three main processes(\tem, \teg, \trm).

Secondly, \teg{} will generate all events from different source handles and sort them by arriving time. And then listened for the request from \tem. At the same time, \trm{} will initialize its information about each router and each buffer.

Finally \tem{} loop working for requesting new event, processing event and finish work.

\subsection{How event information is used?}
\tem{} should process the event by its type. And then send the packet to \trm.

\subsubsection{Arrival Type}
\trm{} will check whether there is more places for saving the packet ,the packet has went to the end or the packet should be lost. And then \trm{} will add some information(such as \nsid{} and \tss)to the packet and send new packet to \tem.

\tem{} will get more events from \teg{} and create a new departure event by the packet's waiting-time and completing time if the packet can be saved. It'll save it to finish list if the packet has been in the end. Or save it to lost list because of there is no more place for saving it.

\subsubsection{Departure Type}
\trm{} will release the place which is allocated by the packet and add new timestamps to the packet. And then \trm{} send the packet back to \tem.

\tem{} receive the packet and create a new arrival event for the packet.

\subsection{How to be routed to next?}
This is the \trm{}'s work.

Because of saving \nsid{} and \sids{} in the packet, \trm{} only has to get the next source id from \sids{} by \nsid{}.

\subsection{How does the main event loop operate to handle arrivals and departures from different queues?\label{sec:erlang_main_event_loop}}
There is no different for \tem{} in many queues or one queues.

What \tem{} has to do is managing all waiting-events ordered by the occurring time. The occurring time for arrival event is the last arriving time and for departure event is the last completing time.

And then \tem{} pops the first of the event and remove it from the event list. The most important thing that is generating new events is depended on \trm{}.

\subsection{How is the generation of packets from multiple independent sources handled?}
This is the \teg{}'s work.

It generated events by the rate and packet length for each independent source handle, and then \emph{merged} them together by sorting on the last arriving time.

\subsection{How is loss rate calculated and stored/batched for each queue (link)?}
After simulating, \tem{} will output the detail information about each packets which are lost or not to a file. In the file, each packet information contains \emph{length}, \emph{sources}, \emph{timestamps}. Whether the packet is lost can be determined by the data of the timestamps field.

If we have these data, we can calculate loss rate for each queue(link) by organizing packets' timestamps. For example, calculating one link's loss rate, we get the packets by one special \emph{sources} and then count these packets.

\subsection{How is end-to-end delay calculated and stored/batched for each end-to-end path?}
It's similar to the loss rate calculation. All results depend on \emph{packets' timestamps}.

I use \emph{Ruby Script} to read the hole packets and put them in order by \emph{sources} to each group. And then, I can calculate the delay time for each group.

\subsection{What's the problem\label{sec:erlang_problem}}
The most problem is the program is running very slow because of increasing the arrival packets. And \emph{why}?

There are some reasons in the program:
\begin{itemize}
  \item The \emph{Feature} of \erlang{} programming language. In order to avoid the lock mechanism in multi-thread programming, \erlang{} don't allow variable changing in running, so it should copy all data from one variable to another. And then there are too many data copying in the program. So it runs very slowly. Please see the result table ~\ref{tab:erlang_running_time}.
  \begin{table}[htp]
    \center
    \begin{tabular}{rl}
      \hline
      Arrival Size & Time(s)\\
      \hline
      30250 & 1 \\
      302500 & 127 \\
      605000 & 361 \\
      605000++ & \emph{I don't know}\\
      \hline
    \end{tabular}
    \caption{The running time of increasing arrival size}
    \label{tab:erlang_running_time}
  \end{table}
  \item Output all packets to the file. Because of this step, we have to do some excessive works: writing data to the file and parsing the file.
  \item The method of the simulation
  \item The hardware problem. Running on my friend's PC, it ran three times faster than mine(please see table~\ref{tab:pc_compare} about the information about PCs)
  \begin{table}[htp]
    \center
    \begin{tabular}{r|cc}
    \hline
    Hardware & Friend's PC & Mine \\
    \hline
    CPU & Core 2 P8600 2.4GHz*2 & Core 2 T5500 1.66GHz*2 \\
    Memory & 4GiB & 1.5GiB\\
    \hline
    \end{tabular}
    \label{tab:pc_compare}
  \end{table}
\end{itemize}

\section{Specification of Network Simulator Design (Scenario II)(\emph{Java} fast)}
\lstset{language=java}

\subsection{Why change to Java}
According to section~\ref{sec:erlang_problem}, I rewrite my program by Java.

When using \erlang{}, I found it's better for Time Driven Model. Because it can use all CPUs for running each model(Router, queue and so on). But when using event driven model, there are only a few models. The advantage of \erlang{} doesn't perform well, but the weak point(All data copying) appeared.

And using Java, I don't have to worry about data copying because all operations is in my control.

\subsection{New Design}
To be similar to \erlang{} Event Driven Model, I write the program in the same principle. But I merge data parsing and simulating together.

When I split data parsing and simulating, I found it should cost a long time to recreate the status of the simulating. So it cost a long time.

\subsection{What information is associated with an event and how is this information used?}

\lstinputlisting[label=src:java_model_event,caption=The data structure of Event, linerange={12-15}]{../../java_src/src/model/Event.java}

\lstinputlisting[label=src:java_model_packet,caption=The data structure of Packet, linerange={12-18}]{../../java_src/src/model/Packet.java}

In Event(source~\ref{src:java_model_event}), it works like \erlang{} Event model(section~\ref{sec:erlang_event_model}).

To be different, the packet(source~\ref{src:java_model_packet}) model is not as complex as \erlang{} version. It only contain the first arrival time and last finish time for calculating delay time, and I add other two fields(pathId,index). By these fields, I can check where it should go and whether it's lost or finish.

\subsection{When a packet completes service , how is it decided where it should be routed to next?}
It depends on the packet's index and pathId. The queue got the path by the packet's pathId and index the next queue Id by \emph{path[index]}. And then the queue update the packet's index.

\subsection{How does the main event loop operate to handle arrivals and departures from different queues?}
It is same to \erlang{} version(section~\ref{sec:erlang_main_event_loop}).

\subsection{How is generation of packets from multiple independent sources handled?}
Be different from the \erlang{} version, I create many packet generators, and its manager.

\lstinputlisting[label=src:java_model_packet_generator,caption=The Packet Generator, linerange={16-73}]{../../java_src/src/model/PacketGenerator.java}

In source~\ref{src:java_model_packet_generator}, it records its left packets and next packet's arriving time. And it support two methods to get new packets: get the next one, or get packets before a special time.

\lstinputlisting[label=src:java_manager_packet_generator,caption=\tpm, linerange={18-59}]{../../java_src/src/manager/PacketGeneratorManager.java}

In source~\ref{src:java_manager_packet_generator}, \tpm{} manages a packet generator's priority queue which order the generator by its \emph{time}. When \tem{} get packets from it, it can return the earliest one or a set of packets which are before a special time.

\tem{} also should manage a priority queue which order the event by its happening time. And when it get new packets, it generates new events and add to its queue.

\subsection{How is loss rate calculated and stored/batched for each queue (link)?}
\lstinputlisting[label=src:java_model_queue,caption=The structure of queue, linerange={22-36, 122-160}]{../../java_src/src/model/Queue.java}
In source~\ref{src:java_model_queue}, the queue record each arriving packet's number(line~\ref{java:queue:receivelossbatch}), and if its number is equal the \emph{batch size} it create a new record for loss. And in it, it also should record this batch's loss number(line~\ref{java:queue:lossbatchlist}).

\subsection{How is end-to-end delay calculated and stored/batched for each end-to-end path?}
In source~\ref{src:java_model_queue}, the queue record each finishing packet's number(line~\ref{java:queue:receivedelaybatch}) for each path, and if its number is equal the \emph{batch size} it create a new record for delay time of the path. And in it, it also should record this batch's total delay time(line~\ref{java:queue:nowdelay}).
